linux应急响应

最近在进行应急响应时遇到linux系统比较多，之前在对linux系统进行排查的时候，没有一个严谨的流程，导致在溯源分析的过程比较混乱，常常一个命令运行多遍。所以就想对linux系统的应急进行一下总结，具体需要排查哪些方面和使用哪些命令，流程是怎样的。

linux出现问题主要是病毒挖矿和webshell植入两种场景，我们就从这两种场景分别进行总结。

病毒挖矿

在接到应急的项目后。我们在到达现场，首先需要和客户沟通如下内容：服务器是否存在Web服务，服务器的口令强弱，服务器的网络架构。沟通的目的在于了解挖矿病毒是由什么方式植入，如果是存在Web服务，需要进一步对Web服务进行排查，口令强弱在于可能会利用ssh弱口令直接登录后植入，网络架构的了解是为了存不存在横向移动的风险。对这些内容了解后，我们开始进行具体的排查步骤。

进程服务相关

top

1.挖矿病毒典型的特征的是CPU占用率高，所以我们第一使用Top命令来查看。

可以看到目前的CPU的占用率已经高达97.7%，说明这个程序确实存在问题。

对于top命令，我们关注的点主要有以下几点：1.用户，2.cpu信息，3.时间

用户主要是在top命令最上一行，可以看到目前是1个用户，cpu信息主要关注cpu占用率，进程执行数量，还有时间信息，时间信息代表运行的时间总时长，可以从这里推断病毒植入时间，同时也方便我们查看日志时有目标的去寻找信息。

ls -al /proc/[pid]/exe

2.定位异常文件，我们在Top命令中发现一个异常进程，接着我们就需要定位他的位置，使用命令ls -al /proc/11134/exe来定位进程的文件位置

这条命令可以看到进程所对应的文件位置，同时也能看到程序运行的开始时间，定位在文件位置后，我们ls -al [文件]，可以看到文件创建的时间。

netstat -antp

3.使用netstat -antp查看当前外联情况，我们一般需要看的状态为已连接状态也就是ESTABLISHED，同时对应PID的值来看。可以看到这里存在之前占用CPU高的可疑程序外联的一个IP地址，我们在威胁情报中查询一下这个地址。

在威胁情报中已经收录此地址，为一个矿池地址，这里我们可以初步确定为挖矿程序。

strings

一般来说，在发现挖矿安全事件客户首先做的事断网处理，并且服务器也不会让插入介质，所以我们对可疑程序不能快速的上传至云沙箱中分析，这里就借助Strings命令简单的查看一下文件内容。对于文件内容主要进行关键字筛选集中在pool，pool.，tcp，wallet等。大部分程序会存有钱包地址，地址池地址等。我们通过strings可以看到存在poolwallet，pool.hashvault.pro关键字，且pool.hashvault.pro已经被标记为矿池地址，所以直接能够确定此程序为挖矿程序。

lsof -p [pid]

对于已经确定为病毒程序文件，我们还是先不要着急去kill进程，需要对进程近一步的进行分析，从而防止我们后续无法干净清除病毒程序。lsof -p 11303查看病毒进程调用的所有文件。这里我们可以看到此程序调用的文件较少，无异常文件。

systemctl status pid

这里还需要查询程序是否存在守护进程，如果刚才上面我们直接kill掉进程，挖矿病毒程序还会重新自启动。使用命令systemctl status 11303 ，可以看到未存在守护进程。对于有守护进程的病毒程序，先要kill掉守护进程，接着再kill掉挖矿进程。

crontab -l

经过上面一系列操作，我们已经能找到挖矿病毒程序所有相关的内容，但是我们还需要进一步去确认有无残留的权限维持的相关内容。crontab -l 枚举定时任务，这里我们可以看到并无任何定时任务。

systemctl list-unit-files

对于自启动服务我们同样需要关心，使用systemctl list-unit-files | grep enabled来筛选开机自启动的服务。如果存在与挖矿病毒相关的自启服务，使用命令systemctl disable 服务名关闭。我们需要关注systemd 配置文件：

①/etc/systemd/system 存放系统启动的默认级别及启动的unit的软连接，优先级最高。

②/run/systemd/system，系统执行过程中产生的服务脚本，优先级次之。

③/usr/lib/systemd/system 存放系统上所有的启动文件。优先级最低

时间允许的话可以分别查看这3个文件夹的文件。

user相关

awk -F: ‘$3==0{print $1}’ /etc/passwd

我们检查完服务，进程后，还需要对用户进行检查，防止二次被植入病毒程序。使用awk -F: ‘$3==0{print $1}’ /etc/passwd命令来查询特权用户。

cat /etc/passwd | grep -v nologin

查询除无法登录以外的用户，有无新增cat /etc/passwd | grep -v nologin。

awk ‘/$1|$6/{print $1}’ /etc/shadow

查询可以远程登录的帐号信息，awk ‘/$1|$6/{print $1}’ /etc/shadow。

/var/log相关

在对整个服务器进行检查完成后，还需要对日志进行分析，来还原攻击

/var/log/btmp

登陆失败的用户日志一般存储在/var/log/btmp中，使用lastb可以进行查看。

/var/log/lastlog

所有用户登陆日志在 /var/log/lastlog中，可以使用lastlog来查看

/var/log/wtmp

系统的成功登录、关机、重启等会存储在 /var/log/wtmp中，使用命令 last可以查看。

/var/log/auth

这里需要注意的ubuntu的用户认证日志存储在/var/log/auth.log中，而centos的用户认证日志存储在/var/log/secure中，使用命令cat /var/log/auth.log | grep -i “accepted password”筛选登录成功的日志信息。

使用命令可以查看cat /var/log/auth.log | grep -i “failure”筛选登录失败日志

对于想查看SSH爆破使用命令cat /var/log/secure|awk ‘/Failed/{print $(NF-3)}’|sort|uniq -c|awk ‘{print $2”=”$1;}’可来筛选出来次数，进行一个分辨。从下面可以明显的看到被爆破的痕迹。

/var/log/wtmp

查看机器创建以来登陆过的用户，使用last命令查看。

history

其实history局限性很大，我们看到的history只是SSH连接后的产生记录，对于使用nc，shell，脚本等执行的一些命令是不会记录出来的。从下面可以看到我们只能看到反弹shell命令，具体反弹后输入了什么命令history是不做记录的。

history | more 带时间显示

.bash_history

上面我们提到history的局限性比较大，所以我们需要结合.bash_history的命令一起来看历史的操作命令。

以上是对病毒挖矿应急响应的一个整体流程与命令，基本上是能够将所有的风险项都检测出来，但实际的应急过程中，常常还会被客户单位问一个问题（针对没有web服务的客户单位）：本单位的服务器对外发起的攻击怎么查?其实刚开始对于这个问题自己表示也很懵，除了看历史命令就没有什么方式去看，其实还可以从流量特征方面去分析是否对外发起过攻击，但是具体是什么攻击确实没有方法去看。除非是服务器上留存一些扫描攻击或漏洞利用工具。这里再引入一点，如果发现服务器日志被删除掉，可以进行恢复。

假设我们服务器现在被删除了auth.log与auth.log.1日志文件

第一步先查看文件对应的PID值：lsof | grep auth.log，可以看到PID的值为420，文件对应的描述号为7。

第二步在/proc下找对应的文件：ls -al /proc/420/fd/7

第三步将文件从/proc/420/fd/7拷贝到/var/log/auth.log：cp /proc/420/fd/7 /var/log/auth.log

这样文件就被恢复了，但是需要记得的是，如果使用命令cat /dev/null > /var/log/文件名这种方式的话，是无法进行恢复的。

webshell植入

对于webshell植入类型的应急响应，我们需要的是注意三点，第一点是对网站根目录下所有的文件进行排查，防止留存木马；第二点是对服务器进行排查，防止留存后门；第三点是需要排查清楚通过什么漏洞入侵进的服务器。

首先我们需要了解各中间件日志存放的位置：

weblogic

weblogic会有3种日志，分别是accesslog，Server log和domain log。

对于weblogic的日志位置一般在weblogic安装目录\user_projects\domains\下

tomcat

tomcat日志一般存放在：tomcat安装目录/logs下

如果在logs下未找到，可以在conf/logging.properties查看存放的位置

apache

apache日志一般存放在网站根目录下，要是没有找到可以从httpd.conf配置文件中找：

grep -i”CustomLog” /etc/httpd/conf/httpd.conf

grep -i”ErrorLog” /etc/httpd/conf/httpd.conf

nginx

nginx的日志位置可以从nginx根目录下去找，或者在nginx目录下找到nginx.conf文件来看ningx的日志路径。

如果找到不到nginx.conf文件，先定位nginx进程ps -ef | grep nginx找到目录后，在目录文件下寻找具体文件即可。

Mysql数据库

linux系统下主要以安装mysql为主，为了数据安全，同样还是得查看数据库日志。

先使用SHOW VARIABLES LIKE ‘gen%’;查看数据库操作状态以及操作日志存放的位置，默认general_log是关闭的。

通过位置我们查看日志信息，可以看到其实记录还是很全面的，包括执行过的命令，连接过的IP，对数据库的操作。

同时也会记录对数据库爆破操作。所以，我们的在日常运维的过程中一定要开启日志记录。

使用show full processlist;查看正在对数据库的连接。

示例

这里我们以Tomcat为例，前面我们也提到tomcat的日志的位置，我们直接看日志，发现其中一个IP地址，对/manager/status页面进行爆破（时间间隔短），这个页面也就是tomcat-mangaer页面。

/tomcat/log

在经过尝试后，还是登录成功，应该是爆出来用户名密码，接着在/manager/html/list进行了文件上传，并且上传成功。

紧接着对shell/shell.jsp进行了访问。到这里可以分析到利用了tomcat-manage页面进行口令爆破，同时上传了webshell，进行了连接。

在catalina.log中同样能看到爆破过程。

接着我们去寻找shell位置，tomcat上传的shell一般会在webapps下面，可以看到shell.jsp的文件。

这里我们只是找到一个shell.jsp的文件，我们还需要查找其他的目录是否存在Webshell。

find /目录 -name ‘文件关键字‘

find /usr/local/tomcat -name ‘jsp‘

这里将tomcat目录下所有jsp文件全部罗列出来。

对于这么多jsp文件，我们其实会很没有耐心去一个一个文件看，所以就需要更深的检索。

find /目录 -name ‘文件关键字‘ -ls

将所有的jsp文件的详细信息罗列出来，这样也更方便我们去进行通过每个文件的具体信息来进行排查。

但是在有些时候，项目文件太多，这种方式又显的很笨拙，所以需要进一步再进行命令优化。

find /目录 -name ‘文件关键字‘ -命令集

find /目录 -name ‘文件关键字‘ -amin -10 查找在系统中最后10钟访问的文件

find /目录 -name ‘文件关键字‘ -atime -2 查找在系统中最后48小时访问的文件

find /目录 -name ‘文件关键字‘ -mmin -5 查找在系统中最后5 分钟里修改过的文件

find /目录 -name ‘文件关键字‘ -mtime -1 查找在系统中最后24 小时里修改过的文件

我们查找下最后12小时内修改过的文件，搜索范围又变小了，再结合入侵的时间点，还是相对比较容易找出其他的木马程序。

其实在linux中，还有很多命令去组合进行搜索，找到适合自己的一套搜索命令更能快速去进行问题的排查。后面的排查还需要对服务器进行一个排查，防止对方留存后门程序进行一个持久化的控制。后续的排查过程可以与我们对病毒挖矿类的响应过程进行排查。

总结

在我们进行应急响应的过程中，无论是遇到什么情况，都需要记住，首先和客户需要进行详细的沟通，确认网络环境，确认什么事件。在能够断网的情况下尽量做到断网排查，第一时间不要去着急结束相关进程和删除文件操作，防止后面有些点溯源不到位的情况。其次，我们在做的每一步对文件的操作，拍照或截图留存证据，对于溯源的过程也需要进行证据留存。在排查的过程中，一定要做到细致，不要放过任何的可疑文件，对于一些可疑的进程或程序，追踪他的进程链条总能去判断此程序的可疑性。